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Security is a journey, not a destination 

The Security Development Lifecycle (SDL) 
was created to build security into the 



process of engineering software 




Part of the process is verifying that the 
security measures in place actually work 

Fuzzing can be used for verification 
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Answer These Questions First 



- How do I know if my fuzzing is effective? 

i Have to answer 3 other questions first 
What approach should I take? 
What do I look for when I fuzz? 
How much is enough? 

* Then an effective strategy can be built 
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WHAT APPROACH SHOULD I 
TAKE? 
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What Approach Should I Take? 

Defining the Target 
a What are the Tools? 
- What's Most Effective? 
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Define the Target 



A 



What are you really fuzzing? 

Web Service 
Protocol Parser 
File Parser 
Local Service 

What Type of Data is Being fuzzed? 

Binary 
Text 

Are there Layered Attack Surfaces? 

Is there a wrapper? 

Is it compressed? 

Is there initial validation that would reject fuzzed 
data? 
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What are the Tools? 



Dumb Fuzzers 

Easy to build and easy to use 

Relatively low-investment to find 
a lot of bugs 

Penetration may not be very 
deep 

Preferred method by many in the 
industry A 

Smart Fuzzers / 

High cost of entry 
Format aware \ r 

Highly configurable N 
Better penetration in some cases 
Find different bugs 

Generation vs. Mutation 



Generation 



Dumb 



Smart 



Mutation 
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About Dumb Fuzzing 



Dumb fuzzers are (mostly) not format 
aware, and just flip bits 

Sequential fuzzers 

• Start with a value, and increase/decrease from that 
value until done 

• e.g. 0x00, 0x01, 0x02, ...OxFE, OxFF 

Random Bit-flipping 
Random String/Binary Injection 

Still very effective with great ROI 

Tool tip: Peach and MiniFuzz both do dumb fuzzing 
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Smart Fuzzing Case Study 

• MS07-017 had to do with repeating AN I 
headers 

* 1 st ANIH © 
- 2 nd ANIH © 

* Wrapped by an Exception Handler 

• Have to fuzz the framework and not just the 
values 

- A dumb fuzzer would never find this issue 

• A smart fuzzer could find it 

If the grammar is too strict, it wouldn't fuzz the 
headers and could miss this type of issue 

The debugger has to be smart enough to catch 
first chance exceptions 



Tool Tip: Peach does smart fuzzing too 
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Fuzzing at Microsoft 



We Use Semi-Dumb Mutational Fuzzers First 

• Mutating existing data gives us a high probability of the 
fuzzed data being accepted by the target 

Developing custom Smart fuzzers has not provided 
a very good ROI 

• Smart Fuzzing takes a lot of domain knowledge to build 

• Smart Fuzzers are typically complicated to configure 

Research has led us to use a combined approach 
- Illustrated by the Fuzzing Olympics 

• Providing a minimal amount of initial "Fix-up" in a script 
is much easier than trying to define a type (e.g. CRC's) 

Dumb Fuzzers are easy to deploy 
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Microsoft Fuzzing Olympics 



Several tools competed head-to-head 

Several Internal Mutational Fuzzers 
A Constraint Solver 

Peach - An External Mutational/Generation 

Level playing field 

Same timeframe 
Same targets 

1 text parser, 1 binary parser - both previously 



untested 
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Olympics Findings 



There was a lot of overlap in the bugs found 

Some fuzzers did much better at binary vs. text formats 

No one fuzzer found ALL of the bugs 

A lot of bugs were discovered, including one definitive 
MSRC grade issue 

Many of the bugs found were in close proximity to 
others in the code (major hashes) 

Developing custom file descriptions did not appear to 
provide a very good ROI 

Dumb Fuzzing found the majority of the bugs in the 
Olympics 

Other internal fuzzing efforts support this as well 

Automated Format Analysis found more bugs (minor 
hashes) than any other fuzzer, but it's more complicated 
than that... 
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Olympic Results - Text Parser 
60 distinct crashes 
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Olympic Results - Text Parser 
10 underlying bugs 
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Diversify! 



- A Primary Rule of Fuzzing: 

Change your approach, find different bugs 

* Try a different method 

Mutational 
Generation 
Sequential 
Constraint Solving 

- Fuzzing with a second approach 
measurably increased effectiveness 

10%-300% in this case 
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Make the Most of Your Tools 

Check for penetration 

Validate code coverage 

Consider bypassing or proxying any tricky 
authentications, and test those separately 

- Create custom fuzzers for small hard-to 
reach areas 

Template Reduction (Mutation only) 

Using the smallest number of templates with 
the maximum amount of Coverage 

• Template Reduction increases effectiveness by 
~100%* ■* 

*Based on research by Gavin Thomas, MSRC Engineering 
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Scaling a Difficult Problem 



Problems exist with identifying unique crashes 

The same issue can arise multiple times 

The same issue can arise through multiple code paths 

The same issue can be found across multiple machines 

Classifying the crashes is another issue entirely 

Manual inspection of crash dumps does not scale 
Identifying security issues takes experienced resources 
Takes a lot of time to manually analyze the crash 

Testing produces more crashes than there are 
resources to triage 

Automation can help trim down the triaging 
Grouping crashes by location in code helps 
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Requirements for a Solution 



Performance in Live Debugging 

Security tools have to evaluate every first 
chance exception for security implications 

Minimize False Positives 



Tools must scale, noise blocks that 
Avoid False Negatives 

Categorizing an exploitable crash as not being 
exploitable is a major fault 

Maintainability and Expandability 

The state of the art in exploitation changes, 
tools must keep up 
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Architecture for a Solution 



Rules Driven Engine 

Maintainability 

Ease of understanding the rules 

Processor independence 

The prototype already had too many special cases for 
x86 versus x64 cluttering the code flow 

Human and Machine readable output 

Other tools will be layered on top 
Manual use is still a supported scenario 

Implemented as a Windows® Debugger extension 
(windbg.exe) 
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/exploitable Crash Analyzer 



■ Ho 



What is it? 

Windows debugger extension (Windbg.exe) 
Provides automated crash analysis 
Provides security risk assessment 

How does it work? 

A live crash or dump is created by a debugger on Windows 
Exploitable examines crash data 
Identifies the uniqueness of each crash 
Analyzes data to provide reliable guidance on exploitability 

What is the output? (Bucketizing) 

An exploitability indicator identifies whether the crash is: 

Exploitable 
Probably Exploitable 
Probably Not Exploitable 
Unknown 

i A set of identifying uniqueness indicators 

Hashes 
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Automated 

Crashes 




Triage 

544 Crashes 



71 Unique Stacks 



23 Unique Hashes 

2 Issues Classified as 
Probably Exploitable 

1 Critical Fix 
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Assumptions and Limitations 



Fundamental Assumption 

All input operands in the faulting instruction are under 
the control of the attacker 

• Limitations 

The lightweight flow analysis and the above assumption 
can result in over-assessing risk 

Registers are not aliased by value 

■ Even if EAX and ECX were set to the same value before the 
faulting instruction, we will not consider them equivalently 
tainted 

Changes in registers don't affect special cases 

• EBP-10 is a pseu do- register, unaffected by changes to EBP 
itself 
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lexploitable Crash Analyzer 

Walkthrough 



|«T C:\LPsers\Public\CreshTools\av£S(E - 


WmDbg:611.0001.402 X36 




File Edit View Debug Window 


Help 




& 1 1 § m S. 


oMF |«|s^a^n^g nn^|[g!S!|A fl |g 




Command 




an 



O : 000> g 

(Id2c.5e8) : Access violation - code cOOOOOOS (first chance) 
First chance exceptions are reported before any exception handling. 
This exception may be expected and handled. 

eax=OOOOOOOQ ebx=20000Q00 ecx=0000000c edx=00000000 esi=20000000 edi=0017feb0 
eip=0 04 01145 esp=0017fe94 ebp=0017ff40 iopl=0 nv up ei pi zr na pe nc 

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=Q02b ef 1=0001024 6 

image00400000+0xll45 : 

OO^Q^^^iii^^^^ rep Tno/vj3_jKP-rd^-p4>r— \= = 



tf ffl00> ! exp 1 oitable^ 

E^jlul LaDlll Ljy 1 Lla^Tif ication : CP pOB AB L Y_EXP L O I TABlT 
Recommended Bug Title: Probably ExpoiTSfH^^^eadAcc 

{Hash=0x42 6222 0b. 0x42 057 021) 




■exploitable is run against a crash. The exploitability 
classification is set as Probably Exploitable, and an explanation 
offered below. 



Data Move starting at image004 00000+0x114 5 



JJJ^^s^^s 



s a read access violation in a block data move, and is therefore classified as probably exploitabJ 



0 : 000> 



LnQ,ColQ Sys.0:<Local> Proc 000:ld2c Thrd000:5e3 ASM OVR CAPS NUM 



P C:\L^ers\Pubtic\CrashTools\av.exe - WfnDbg:6.11.0001.402 X36 



File Edit View Debug Window Help 
I e? I m | Si * *i *» ! "ft {? 



Command 



First chance exceptions are reported before any exception handling. 
This exception may be expected and handled. 

eax=00000000 ebx=20000000 ecx=0O000000 edx=00000000 esi=004011S2 edi=00000000 
eip=00401199 esp=O017fe94 ebp=0Q17f f 40 iopl=0 
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b 
image 0 04 00000+0x1199: 

^1^11°° iriov eax,dword ptr [ebx] 



nv up ei pi zr na pe nc 
ef 1=0001024 6 

ds : 002b : 2 0000000=? ???? 77? 



bure is x8 6 



:000> ! exploitable - v _ 
Hc^^^^a^^^fl^^^WJI^T^^^B^^^ 

Executing Processor Architec 
Debuggee is in User Mode 
Debuggee is a live user mode debugging session on the local machine 
Event Type : Exception 

Exception Faulting Address: 0x2 000uH)00 

First Chance w^^-h-i ,-t- Typ & ■ -gmajETT.^ ^rir.qg yTnuTTnu (OxCOOOOOOS) 
Exception Sub-Type :c ffea a Access Violatl 

Faulting Instruction : 004 01199 mov eax f 

Basic Block: 

004 01199 mov eax, dword ptr [ebx] 

Tainted Input Operands : ebx 
0040119b push eax 

Tainted Input Operands : eax 
0040119c call eax 

Tainted Input Operands: eax, StackContent s 



Exception Hash (Ma j or /Minor ) : 0x42 6222 0b .0x420571 




Stack Trace : 
image004 00000+0x1199 
image 004 00 000+0x1560 
kernel32 ! BaseThreadlnitThunk+Oxe 

ntdll ! RtlUserThreadStart+0x23 

ntdll ! RtlUserThreadStart+Oxlb 
Instruction Address: 0x401199 

Description: Data from Faulting Address controls Code 
Short Description: TaintedDataCoa^^^^^^^ik 
Exploitability Classif ication CPROBABL Y" EXPLOITA'£ l"! 
Recommended Bug Title : Probablyffiffffe* 

(Hash=0x42 6222 0b. 0x42 057121} 



Using iexploitable Crash Analyzer in verbose mode (-vj shows much more information about 
the crash. The type of exception is called out. The uniqueness identifiers are highlighted 
here, to discern if the issue is related to another crash. 

The Exploitability Classification section stays the same,, as it is the key information that many 
users are interested in. This issue is probably exploitable, because the user can define what 
branch of code is taken. 



!ffi 




CaTa from Faulting Address controls Code Flow starting at image 004 00000+0x1199 




0 : 000> 



LnQ.ColO SysO:<Local> Proc000:lbl8 Thrd000:lec4 ASM OVR CAPS NUM 



P C:\Ll^ers\Pubtic\CrashTools\ay.exe - W[nDbg:6.11.0001.402 X36 



File Edit View Debug Window Help 

I & | | ill § "4 ^1 fl W 



Command 



Ed 



|eax=2 0000000 ebx=7efde000 ecx=00000000 edx=0 0000000 esi=00000000 edi=0000000O 
eip=004 01Q6f esp=O017fe94 ebp=OO17ff40 iopl=0 nv up ei pi zr 11a pe nc 

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b ef 1=0001024 6 

*** WARNING: Unable to verify checksum for image 004 00000 

*** ERROR: Module load completed but symbols could not be loaded for image004 00000 
image004 00000+0xl06f : 

0040106f 8a09 mov cl^byte ptr [ecx] ds :002b : 00000000=?? 

0:000> ! exploitable -v 
Ho s tMachine \ HostUser 

Executing Processor Architecture is xS6 
Debuggee is in User Mode 

Debuggee is a live user mode debugging session on the local machine 
Event Type: Exception 
Exception Faulting Address: 0x0 

First Chance Exception Type: S T ATUS_AC CES S_V I OL AT I ON (0xC0000005) 
Exception Sub-Type : Read Access Violation 

Faulting Instruction : 004 0106f mov cl,byte ptr [ecx] 

Basic Block: 

0040106f mov cljrbyte ptr [ecx] 
Tainted Input Operands: ecx 
00401071 mov byte ptr [ebp-91h] , cl 

Tainted Input Operands : cl 
00401077 mov esi, Of f f f f f f eh 
004 0107c mov dword ptr [ebp-4],esi 
004O107f jmp image00400000+Oxl098 (00401090} 

Exception Hash (Major/Minor): 0x42 6222 0b . 0x42 052 02 1 

Stack Trace : 
image004 00000+0xl06f 
image004 00000+0x1560 
kernel32 ! BaseThreadlnitThunk+Oxe 

ntdll ! RtlUserThreadStart+0x23 

ntdll ! _RtlUserThreadStart+Oxlb 
Instruction Address: 0x4 0106f 



Description :<j^ad Acce ss Violation n ear NU LI 
Short Description^ — 




The description includes a simple assessment of what happened. The 
exploit ability classification shows that this is probably not exploitable, and the 
reason is explained briefly below. 



Exploitability n ^ c^i f i i nngppnR^ QLY NOT EXPLOIT^JiP^ 
Recommended Bug Title: Read Access Vio^^5^Te^r"kjLL startin g at j image 004 00 00 0+0x1 06f (Hash=0x42 6222 0b . 0x42 052 021} 

ghis _Ls a user mode read access violation near null, and is probably not ex ploitab le 
|0: 000> f 



LnG, ColO Sy&0:<Local> Proc 000:ld2c Thrd000:5eS ASM OVR CAPS NUM 



P C:\Users\FliHic\CrashTools\av.ere - Win Dbg:&11.0001.402 X36 



File 
\ & 



Edit View 



Debug Window 

I -hi L e -4 hi. 1 



Help 

74 



Command 



SUB 



0 : 000> g 

(Ibl8.1ec4) : Access violation - code c0000005 (first chance) 
First chance exceptions are reported before any exception handling. 
This exception may be expected and handled, 

eax=O0000000 ebx=2 0000000 ecx=00000000 edx=0 0000000 esi=004011fe edi =00000000 
eip=004 01215 esp=O017fe94 ebp=0017.f f 40 iopl=0 tiv up ei pi zr na pe nc 

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b ef 1=0001024 6 y 

image 004 00000+0x12 15 : 

00401215 ffl3 call dword ptr [ebx] ds 002b : 2 00C 1 I .::=?■? 

0:000> ! exploitable 

Exploitability Class ifica^^jw— fli*#WS*^ — 

Recommended Bug Ti tk^* Exploitable - Read Access Violation on Control Flow 
0x42 6222 0b. 0^42057621) ■ 




The title in this instance tells the user what any reasonable security 
expert could at a simple glance, the crash happened because the user 
controls execution. The title is appropriately "scary" to get the proper 
attention. 



rting at image 004 00000+0x12 15 (Hash= 



Access violations not near null in control flow instructions are considered exploitable. 



0: 000> 



LnQ.ColO SysQ:<Local> Proc000:lbl8 Thrd 000:1 ec4 ASM OVR CAPS NUM 



Who Benefits from Exploitable? 



Exploitable Crash Analyzer helps 3 rd party 
software Developers and Testers working on 
Microsoft® platforms to manage their workload 

Developers and Testers don't have to be security experts in order 
to identify many security issues 

Can identify and categorize crashes with security implications 
quickly 

Helps to prioritize work based on exploitability of crashes 

"Exploitable" Elevation of Privilege bug may need immediate attention 
"Probably Not Exploitable" Divide by Zero bug is likely a lower priority 

Decreases the amount of time needed to analyze crashes for 
exploitability 

Security Eco System 

Helps standardize exploitability reporting within companies and 
across the Security Ecosystem 
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Use Inside of Microsoft 



Used by Security Tools for crash 
categorization and bucketization 

- Used by Developers, Testers and Support 
Engineers to evaluate the implications of 
crashes on products in development 



Tool Tip: Include Exploitable output when reporting 
vulnerabilities 
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When to stop fuzzing? 



An arbitrary number of iterations? 

100K,250K,500K, 1M? 

When you stop finding bugs? 

How long to wait before your first bug? 
When will you find your next bug? 

Some complex formula? 

Parser complexity 
File size 
Code coverage 
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Case Study: Windows Vista^Fuzzing 



Fuzzed from September '05 to November 
'06 

• 250+ file parsers fuzzed 

• Bugs found and fixed 

• 350M iterations total 

So, fuzz a 1 million iterations and fix 1-2 
bugs? 

• Perhaps, but that might not be practical 
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Prelude to Windows Vista Statistical View 



Definitions 

• Parser: product code that interprets file data 

Bug: reproduced failure in parser with distinct cause 
Iteration: loading one fuzzed file into parser 

• Crash: automatically detected failure, grouped on distinct call stack 
Buggy parser: parser containing at least one crash found in Vista 

^ Counts: 

• Parsers: 250+ 
Iterations: 350 million 
Buggy Parsers: 120 
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Windows Vista Stats: 
Effectiveness at various counts 




More Windows Vista Stats: 
Fuzzing Cost per crash 
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Windows Vista Fuzzing Conclusions 



- Fuzz at least 500K for any exposed formats 

Optimized templates can double the effectiveness 

• KEEP FUZZING if you are finding bugs 

Wait a minimum of 250K since your last new crash 

• Consider ending points based on data, such 
as: 

Number of crashes 
Iterations since last crash 
Code coverage 
Code complexity 
Complex statistical models 

• When you have exhausted 1 fuzzer (more or 
less) try another method 
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Add the sliding window 






500K+0 


500K+250KA 


500K+500KA 


% Buggy Parsers 


92% 


92% 


92% 


% Crashes 


69% 


91.8% 


92.4% 




• 500K gives high confidence that the parser is 
fairly solid if no crashes are found (90+%) 

250K sliding window gives 20+% boost in bug 
finds 

But, an additional 250K window only gives <1 % 
boost 

Is it still better to fuzz longer? 

Certainly, fuzzing longer with many approaches is ideal 
This gives a reasonable practical baseline. 
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Applying Our Learning 



Windows 7 @ File Fuzzing Effort 

>10B iterations total 

• Fuzzers were more mature 
Multiple types of fuzzers were used 

• 400+ file parsers fuzzed 

nterestingly, about the same number of issues 
found ana fixed 

• Compared to Windows Vista 

250+ file parsers fuzzed 
350M iterations total 
A number of issues found and fixed 

Fuzzing got better, bugs stayed the -same 

It takes MORE EFFORT to find crashes with 
fuzzing on an application as bugs are fixed 
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Conclusions - 

A Practical Guide to Fuzzing 

Invest up front in choosing your approach 

Identify targets 
Choose the best tools 

Choose optimal inputs (Template Reduction) 

• Diversify 

Consider a mix of fuzzing tools and approaches 

Use Exploitable Crash Analyzer 

Reduces triage time 

Highlights important security issues quickly 
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Conclusions (cont.) 



Fix bugs aggressively 

If there are too many bugs, consider removing 
the parser 

Fuzz long enough 

At least 500K for reasonable assurance 

Keep fuzzing while you are still finding new 
bugs 

• At least 250K Since the last bug 

Refuzz after fixes to ensure a quality 
release 

Mature the fuzzing efforts over time, don't 
stagnate 
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Thanks! 



Michael Eddington (Leviathan) 

Microsoft - Adel Abouchaev, Dustin Duran, Tom 
Gallagher, Damian Hasse, Rob Hensing, 
Shawn Hernan, Vassilii Khachaturov, Scott 
Lambert, Michael Levin, Dan Margolis, Nachi 
Nagappan, Peter Oehlert, Andy Renk, Hassan 
Sultan, Gavin Thomas, Chris Walker, Dave 
Weinstein, Lars Opstad, Eric Douglas 
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Links 



For more information on Microsoft's 
Security Science and Exploitable Crash 
Analyzer, please visit: 

httD://www.microsoft.com/securitv/msec/ 



And the Security Research & Defense 
(SRD) blog: 
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